home *** CD-ROM | disk | FTP | other *** search
- Path: engnews1.Eng.Sun.COM!taumet!clamage
- From: kanze@gabi.gabi-soft.fr (J. Kanze)
- Newsgroups: comp.std.c++
- Subject: Re: basic_string<T>::npos
- Date: 28 Jan 1996 17:03:04 GMT
- Organization: GABI Software, Sarl.
- Approved: clamage@eng.sun.com (comp.std.c++)
- Message-ID: <KANZE.96Jan28160100@gabi.gabi-soft.fr>
- References: <4e8r8a$9ir@bmtlh10.bnr.ca>
- NNTP-Posting-Host: taumet.eng.sun.com
- Content-Type: text
- X-Nntp-Posting-Host: gabi.gabi-soft.fr
- In-Reply-To: "john's message of 26 Jan 96 05:06:06 GMT
- Content-Length: 1775
- Originator: clamage@taumet
-
- In article <4e8r8a$9ir@bmtlh10.bnr.ca> "john (j.d.) hickin"
- <hickin@bnr.ca> writes:
-
- > From the October draft (I think); the basic_string class interface has these
- > declarations:
- >
- > typedef typename Allocator::size_type size_type;
- > ...
- > static const size_type npos = -1;
- >
- > It is my understanding that the Allocater::size_type should be an unsigned
- > flavour. If this is indeed the case, are we to interpret nops as having the
- > value (size_type)(-1) ?
-
- Yes. And the various definitions of arithmetic on unsigned types means
- that in fact, this must be the largest value that the given unsigned
- type can contain.
-
- At least, the above is true for the built-in unsigned types. I'm
- intreged by the idea that size_type could conceivably be a user defined
- type. In particular, consider an extensible unsigned type, conceptually
- unbound (and in reality only bound by available memory). Presumably, it
- will have a constructor for unsigned; the compiler will convert -1 to
- (unsigned)(-1); on a 16 bit machine, 65536. If the purpose of using
- this special type is precisely to obtain the extended range, we have a
- problem.
-
- I suspect that the requirement should be: size_type must be an unsigned
- type with a conversion from int for which -1 results in the largest
- possible value. An extensible unsigned type, as above, would require a
- constructor which takes an int (as well as the one with unsigned), and
- handle -1 by converting to some sort of special `infinity'.
- --
- James Kanze (+33) 88 14 49 00 email: kanze@gabi-soft.fr
- GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
- Conseils, Θtudes et rΘalisations en logiciel orientΘ objet --
- -- A la recherche d'une activitΘ dans une region francophone
-
- [ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
- Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
- is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
-
-